Brings in line with Scala 2 spec.

This mimics scalac's behavior (but not the official syntax; in fact the
official syntax seems to be ambiguous.

Did not handle this case before.

Idea: when printing, we should be more lenient about conditions that
would otherwise cause an assertion failure, because we want to avoid
triggering further assertions while diagnosing previous errors. As a start
we generalize an assertion that RefinedTypes cannot be created after erasure.
This gets triggered when playing around with printing lambdas at erasure time
(see following commit): erasure runs at phase erasure + 1, so ctx.erasedTypes is true,
but we might still want to print lambdas then, and printing lambdas will create new
refined types as of next commit.

... makes diagnostics more legible.

Previously we could have returned true here yet a subsequent
lambdaArgIndex would fail with a Numberformat error. This scenario
is prevented now.

Need to generate new type if variance differs from old one.

Use the proposed Lambda syntax

  [HK$0, ..., HK$n] => body

for them.

testLifted widened a type to an some base type constructor when comparing with
a type lambda. This can return false positives if the widened type is on the
right of the comparison. The fix adds a parameter to testLifted indicating
whether widening is permitted.

This was uncovered by previous commit "Fix isSubType bug ...".
Also removed two redundants ".fresh" calls in "fresh.addMode".

The test case that caused all previous commits in this branch.

This gives us a cheap way to bound the search of all baseclasses in
testLifted.

lookupRefined now reduces fully instantiated lambdas.

It's a more logical home for them than the Context object.

Previously, this fell back to toString

As test case IterableDotty shows, there can be a cycle

  findMember  -->  &  -->  <:<  -->  hasMatchingMember -->  findMember

which leads to an infinite recursion. This commit avoids this by
keeping track of names of outstanding findMember searches and falling
back to forming AndTypes instead of `&' is we repeat a findMember
search on a name seen before after a certain recursion depth.

Displaying stuff should never report an exception or cause more messages to be displayed that
relate to the displaying.

More refular that way. Also, change some raw printlns in low-level
code to reporter.printlns in order to harden them against prints over prints.

Typecomparer is not a good place because it gets re-generated for new context,
which causes the counts to be reset.

Adds IterableSelfRec.scala which caused lockup of the compiler.
After a lot of work the problem was determined to be polyomial or
exponential behavior of the compiler when executing findMember
on refined types that contain several bindings where the
resutling & causes a recursive invokation of findMember with
the same name. We do have a stop for this now, but if the
stop comes too late the runtime will grow very fast.

Problem addressed by kiccking in earlier with the stopping logic.